Date: Tue, 27 Jul 93 04:30:05 PDT From: Advanced Amateur Radio Networking Group Errors-To: TCP-Group-Errors@UCSD.Edu Reply-To: TCP-Group@UCSD.Edu Precedence: Bulk Subject: TCP-Group Digest V93 #191 To: tcp-group-digest TCP-Group Digest Tue, 27 Jul 93 Volume 93 : Issue 191 Today's Topics: convers-ping-pong release 1.18 conversd for wampes OS/2 NOS version status and misc sbrk() declaration ???? Undelivered mail (2 msgs) Z80 SIO and SCC (2 msgs) Send Replies or notes for publication to: . Subscription requests to . Problems you can't solve otherwise to brian@ucsd.edu. Archives of past issues of the TCP-Group Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives". We trust that readers are intelligent enough to realize that all text herein consists of personal comments and does not represent the official policies or positions of any party. Your mileage may vary. So there. ---------------------------------------------------------------------- Date: Mon, 26 Jul 93 11:11:19 CDT From: andyw@aspen.cray.com (Andy Warner) Subject: convers-ping-pong release 1.18 To: dc6iq@insu1.etec.uni-karlsruhe.de Fred wrote: > > [...] > > from the convers.conf file > > hostname > > host host:3600 > > > > which will make the Linux kernel (net-2) to make a tcpip connect to the > > host named in the convers.conf :3600 being the port number.. > > Over slow links via my router (wnos) the conversd program appears to hand up > > untill the perm link is established once established any other logins to the > > conversd works fine... > > This is normal - You should use this to connect via ethernet, not over > slow links. If the code looks at all like the "vanilla" conversd.c, you can just put a p->retrytime = 0; after the call to update_permlinks() in read_configuration(). I think this has the effect of establishing the permlinks asynchronously. I did this when I couldn't figure out how else to connect slow permlinks.... > [...] I have some users who telnet directly to port 3600 on my (SunOS based) converse server. It appears that conversd does not use CRLF to terminate lines - should this be viewed as a bug in conversd, or should they manually have to tweak their telnet options ? (tricky call without any definative converse specification :-)) -- andyw. N0REN/G1XRL andyw@aspen.cray.com Andy Warner, Cray Research, Inc. (612) 683-5835 ------------------------------ Date: Mon, 26 Jul 93 16:49:35 CET From: BARRY TITMARSH Subject: conversd for wampes To: TCP-GROUP , Ok thanks for the infomation on the new version, on the ftp-site. noted your comments on the host host:socket_number in the convers.conf the new version works fine even with sym links for the other copies of the daemon `conversd` Again thanks for takeing the time out to produce it. Barry G8SAU/DC0HK @ various IP's ------------------------------ Date: Mon, 26 Jul 93 09:26:20 cst From: kf5mg@vnet.IBM.COM Subject: OS/2 NOS version status and misc To: TCP-Group@UCSD.Edu Tried sending a message to Walt C. asking about NOS and PMAIL for OS/2. My message got returned as undeliverable. You still out there Walt? Wondering if you've made any progress on your new versions of tcp/ip for OS/2. Also wanted to know if the source for PMAIL was available and if you've played with the Borland, OS/2 compiler. 73's de Jack - kf5mg Internet - kf5mg@kf5mg.ampr.org - 44.28.0.14 AX25net - kf5mg@kf5mg.#dfw.tx.usa.na - home (817) 488-4386 Worknet - kf5mg@vnet.ibm.com - work (817) 962-4409 ------------------------------ Date: Mon, 26 Jul 93 07:31:27 -0700 From: karn@qualcomm.com (Phil Karn) Subject: sbrk() declaration ???? To: J.R.Jagger@sheffield-hallam.ac.uk I rewrote the grabcore() routine. It now calls DOS's memalloc() routine instead of sbrk(). You should start with a more recent version of the code if you want to hack it down, there are a lot of bug fixes there, not just code growth. Phil ------------------------------ Date: Wed, 21 Jul 93 17:15:24 MET From: MAILER@CSPGUK11.BITNET (Network Mailer) Subject: Undelivered mail To: MAILER%CSPGUK11.BITNET@Sdsc.Edu ----------------------------Original message---------------------------- ----------------------------Original message---------------------------- Your mail was not delivered to some or all of its intended recipients for the following reason(s): No such local user: RSCS --------------------RETURNED MAIL FILE-------------------- Received: by CSPGUK11 (Mailer R2.07) id 0957; Wed, 21 Jul 93 17:15:24 MET Date: Wed, 21 Jul 93 17:02:34 MET From: Network Mailer Subject: Undelivered mail To: RSCS@CSPGUK11 Your mail was not delivered to some or all of its intended recipients for the following reason(s): FROM: or SENDER: inconsistent with spool file origin. --------------------RETURNED MAIL FILE-------------------- Received: by CSPGUK11 (Mailer R2.07) id 0222; Wed, 21 Jul 93 17:02:35 MET Received: from ucsd.edu by Sdsc.Edu (sds.sdsc.edu STMG) via INTERNET; Sun, 18 Jul 93 08:21:17 GMT Received: by ucsd.edu; id AB03154 sendmail 5.67/UCSD-2.2-sun Sat, 17 Jul 93 23:24:29 -0700 Errors-To: tcp-group-relay@ucsd.edu Sender: tcp-group-relay%UCSD.EDU@Sdsc.BITnet Precedence: List Received: from plains.NoDak.edu by ucsd.edu; id AA03148 sendmail 5.67/UCSD-2.2-sun via SMTP Sat, 17 Jul 93 23:24:27 -0700 for /usr/mail/listhandler tcp-group Received: by plains.NoDak.edu; Sun, 18 Jul 1993 01:24:25 -0500 From: ortmann%plains.NoDak.edu%UCSD.EDU@Sdsc.BITnet (Daniel Ortmann) Message-Id: <199307180624.AA00833@plains.NoDak.edu> Subject: NOS on MS-Windows? To: tcp-group%UCSD.EDU@Sdsc.BITnet (tcp group) Date: Sun, 18 Jul 93 1:24:24 CDT X-Mailer: ELM [version 2.3 PL11] 1) Has anyone compiled any of the NOS family on MS-Windows? 2) Has anyone done it using MS Visual C++?? 3) If it has not been done, then what are your thoughts on the difficulty? -- Daniel "un?X" Ortmann (talmid) NDSU Electrical Engineering ortmann@plains.nodak.edu shalom Fargo, North Dakota ------------------------------ Date: Wed, 21 Jul 93 17:15:34 MET From: MAILER@CSPGUK11.BITNET (Network Mailer) Subject: Undelivered mail To: MAILER%CSPGUK11.BITNET@Sdsc.Edu ----------------------------Original message---------------------------- Your mail was not delivered to some or all of its intended recipients for the following reason(s): No such local user: RSCS --------------------RETURNED MAIL FILE-------------------- Received: by CSPGUK11 (Mailer R2.07) id 0986; Wed, 21 Jul 93 17:15:34 MET Date: Wed, 21 Jul 93 17:03:00 MET From: Network Mailer Subject: Undelivered mail To: RSCS@CSPGUK11 Your mail was not delivered to some or all of its intended recipients for the following reason(s): FROM: or SENDER: inconsistent with spool file origin. --------------------RETURNED MAIL FILE-------------------- Received: by CSPGUK11 (Mailer R2.07) id 0269; Wed, 21 Jul 93 17:03:00 MET Received: from ucsd.edu by Sdsc.Edu (sds.sdsc.edu STMG) via INTERNET; Sat, 17 Jul 93 07:40:24 GMT Received: by ucsd.edu; id AA13632 sendmail 5.67/UCSD-2.2-sun Fri, 16 Jul 93 22:44:45 -0700 Errors-To: tcp-group-relay@ucsd.edu Sender: tcp-group-relay%UCSD.EDU@Sdsc.BITnet Precedence: List Received: from SABEA-OC.AF.MIL by ucsd.edu; id AA13618 sendmail 5.67/UCSD-2.2-sun via SMTP Fri, 16 Jul 93 22:44:33 -0700 for /usr/mail/listhandler tcp-group Received: by sabea-oc.af.mil (5.59/25-eef) id AA26398; Sat, 17 Jul 93 00:41:09 CDT From: ssampson%sabea-oc.af.mil%UCSD.EDU@Sdsc.BITnet (Mr. Sampson) Message-Id: <9307170541.AA26398@sabea-oc.af.mil> Subject: 9600 Experiances To: TCP-Group%UCSD.EDU@Sdsc.BITnet Date: Sat, 17 Jul 1993 00:41:05 -0500 (CDT) X-Mailer: ELM [version 2.4 PL13] Content-Type: text Content-Length: 1149 Swinging to the hardware side for a moment... I've recently been experimenting with 2 meter FM 9600 (have a lot of experiance with a Tekk on 440) and am amazed at how poorly it performs. I modified an ICOM 228A both to keep the receiver on all the time (it shuts it off during transmit as designed) and the normal VCO and Discriminator taps. After discussing it, I'm pretty much convinced that the final IF filter is the culprit. I'm using a PacComm TNC which has a 5 kHz cut-off on its input filter. My theory is that 4800 Hz is the highest modulating frequency, so the modulation index at 3 kHz deviation would be .625. Using a Bessel chart shows +/- 3 sidebands for (6 x 4800) 28.8 kHz Bandwidth. I assume the FIR filter on transmit greatly attenuates the third sideband so we probably only need (4 x 4800) or 19.2 kHz. The trouble is my ICOM (and most other rigs) has a 455 kHz filter marked with an 'E'. PacComm says an 'E' is 15 kHz and a 'D' is 20 kHz. I'm not sure what the 10.7 MHz IF has in it. What's the general consensus on this? Do those running 9600 sucessfully change these out, or is my math all wrong? --- Steve N5OWK ------------------------------ Date: Mon, 26 Jul 93 12:39:05 BST From: A.D.S.Benham@bnr.co.uk Subject: Z80 SIO and SCC To: TCP-Group@UCSD.Edu I've been trying to sort out a bug in the KISS ROM for the TNC-220, and during the course of this I've come across something odd with the use of the Z80 SIO and SCC chips. As the SCC chip (8530) is also used for NOS, I've got the same "problem" with the code for the SCC driver. Am I being stupid, or is there really a problem? Both the SCC and SIO chips use a two-stage method to access their internal registers: a write operation to the control register to specify the internal register to be accessed, and then a read or write operation to the control register to actually access the register. Now all the code I've been looking at has internal registers being accessed =both= by foreground routines and by interrupt routines. This is where I have a problem. Take the following examples: ========================= Foreground Code ... Write to Control Register, specifying register 4 Read Control Register ... (This reads register 4) ========================= Interrupt Code ... Write to Control Register, specifying register 3 Write to Control Register ... (This writes to register 3) =========================== Now each routine works fine =in isolation=. But what happens if an interrupt occurs whilst the foreground code is executing the "Write to Control Register, specifying register 4" instruction? As I see it, the processor will finish the instruction (so the internal register pointer is set to point to register 4), and then call the interrupt routine. The interrupt routine will do the "Write to control Register, specifying register 3" instruction, except that this will be taken by the chip as a write operation to register 4. The chip then resets the internal register pointer to point to register 0. Now the interrupt routine sends the data it thinks it is writing to register 3, except the chip is expecting a "set register pointer" instruction - so the register pointer could be set to an unspecified value. Then the interrupt routine returns, and the foreground routine continues and does the control register read... except the internal register pointer is probably not pointing to the right register any more. So, in this example, both the foreground and interrupt routines have executed code which is not that which was intended (in my experience, this is "a bad idea"). I'd have expected that if foreground and background tasks could both access the chip, then the foreground code would mask interrupts during the two-operation access cycle (in other words, as the access operation is not atomic, a locking mechanism is needed). The Z80 SIO and SCC are at least 10 years old though, and the TNC KISS ROMs don't have any special coding to get around this problem. (I was expecting Disable Interrupts Write to Control Register, specifying register pointer Read/Write Control Register Enable Interrupts in the foreground routine. The interrupt routines in the KISS ROMs can't themselves be interrupted, so they need no additional work). So am I being particularly thick and missed something fundamental? Or is there really a potential problem lurking in lots of code? Andrew Benham -------------------------------------------------------------------- adsb@bnr.co.uk BNR Europe Ltd, London Road, Harlow, Essex CM17 9NA adsb@bnr.ca +44 279 402372 Fax: +44 279 402029 Home: g8fsl@g8fsl.ampr.org [44.131.19.195] G8FSL@GB7HSN -------------------------------------------------------------------- ------------------------------ Date: Mon, 26 Jul 93 07:29:47 -0700 From: karn@qualcomm.com (Phil Karn) Subject: Z80 SIO and SCC To: A.D.S.Benham@bnr.co.uk I wrap a "disable/restore" sequence around my references to the SCC's registers. That makes the accesses atomic. Phil ------------------------------ End of TCP-Group Digest V93 #191 ****************************** ******************************